@cdavis5e this is good! Thanks for this catch!
You'll notice the PR is blocked by our workflow, can you reopen this against our dev branch please?

@Martinski4GitHub

Doing a code review of this, I'm thinking this PR might end up conflicting a bit with my open PR: #498

The reason is that I am rolling us back to using the long version with -gnuton(x) and this PR would strip the -gnuton(x) from the returned version.

Any thoughts or input?

In the function of: GetLatestFWUpdateVersionFromGitHub
My PR: would make the variable: routerVersion=3004.388.9.2-gnuton1

But if I merge this PR in as is; then the variable: urlVersion would return without the -gnuton1 suffix, and the final match would fail:
if [ "$urlVersion" = "$routerVersion" ]

@cdavis5e can you also modify this so it wouldn't conflict with the upcoming planned PR to return the long version (-gnuton1 suffix included)

In the function of: GetLatestFWUpdateVersionFromGitHub My PR: would make the variable: routerVersion=3004.388.9.2-gnuton1

But if I merge this PR in as is; then the variable: urlVersion would return without the -gnuton1 suffix, and the final match would fail: if [ "$urlVersion" = "$routerVersion" ]

@cdavis5e can you also modify this so it wouldn't conflict with the upcoming planned PR to return the long version (-gnuton1 suffix included)

Yeah, that would be the best way to integrate the fixes in this PR.

So far, I've seen ubi, nand_squashfs, and puresqubi. While I'm at it, tighten up the REs.

Fixes updating models such as the ZenWiFi XT8 (RT-AX95Q) that use puresqubi or nand_squashfs Gnuton images.

Great catch WRT the different file names/extensions!!

In the function of: GetLatestFWUpdateVersionFromGitHub My PR: would make the variable: routerVersion=3004.388.9.2-gnuton1
But if I merge this PR in as is; then the variable: urlVersion would return without the -gnuton1 suffix, and the final match would fail: if [ "$urlVersion" = "$routerVersion" ]
@cdavis5e can you also modify this so it wouldn't conflict with the upcoming planned PR to return the long version (-gnuton1 suffix included)

Yeah, that would be the best way to integrate the fixes in this PR.

It's a small tweak to make, but otherwise I agree.
It's a good catch and surprised I missed it before.

It's clear to me because I'm only testing with a ubi router from Gnuton. Perfect example of why "it works for me" doesn't always cut it 😜

In the function of: GetLatestFWUpdateVersionFromGitHub My PR: would make the variable: routerVersion=3004.388.9.2-gnuton1
But if I merge this PR in as is; then the variable: urlVersion would return without the -gnuton1 suffix, and the final match would fail: if [ "$urlVersion" = "$routerVersion" ]
@cdavis5e can you also modify this so it wouldn't conflict with the upcoming planned PR to return the long version (-gnuton1 suffix included)

Yeah, that would be the best way to integrate the fixes in this PR.

It's a small tweak to make, but otherwise I agree. It's a good catch and surprised I missed it before.

It's clear to me because I'm only testing with a ubi router from Gnuton. Perfect example of why "it works for me" doesn't always cut it 😜

Exactly, LOL!!! A similar situation happened with scMerlin's "WAN Uptime" feature, where we missed the "Dual WAN with Failover" setup because we don't have it to test and validate with. That's why Beta testing with external users is so critical.

In the function of: GetLatestFWUpdateVersionFromGitHub My PR: would make the variable: routerVersion=3004.388.9.2-gnuton1
But if I merge this PR in as is; then the variable: urlVersion would return without the -gnuton1 suffix, and the final match would fail: if [ "$urlVersion" = "$routerVersion" ]
@cdavis5e can you also modify this so it wouldn't conflict with the upcoming planned PR to return the long version (-gnuton1 suffix included)

Yeah, that would be the best way to integrate the fixes in this PR.

It's a small tweak to make, but otherwise I agree. It's a good catch and surprised I missed it before.
It's clear to me because I'm only testing with a ubi router from Gnuton. Perfect example of why "it works for me" doesn't always cut it 😜

Exactly, LOL!!! A similar situation happened with scMerlin's "WAN Uptime" feature, where we missed the "Dual WAN with Failover" setup because we don't have it to test and validate with. That's why Beta testing with external users is so critical.

It's so so true. Without a proper diverse user base that's actually providing useful feedback (that last bit on useful feedback is key) you can spin your tires in the mud.

Even though 90-95% of people may not have that setup at home. As soon as a user mentioned the Dual WAN setup I went. "Oh yeah that's a totally valid configuration I didn't even think about".

"Worked for me" up until that point too 😜 but can always be improved!

@Martinski4GitHub

Seems to me that @cdavis5e opened a PR and then disappeared? lol
I had responded to him within no more than half an hour when this was opened!

It's now been 4 days with no movement so I made my own PR:
#501

And closing this one.

@Martinski4GitHub

Seems to me that @cdavis5e opened a PR and then disappeared? lol I had responded to him within no more than half an hour when this was opened!

It's now been 4 days with no movement so I made my own PR: #501

And was close this one.

Yeah, that's fair. There was plenty of time to reply, even if it had been just a simple: "I don't have time at the moment."
In any case, the poster will get their due credit.